This invention relates generally to systems and methods for installing application program suites and, more particularly, relates to the number and type of install actions, and their availability, selection, and display.
With the continued growth and specialization of various software applications for both business and residential users, software original equipment manufacturers (OEMs) and secondary value added providers (VAPs) have begun selectively combining these applications into suites. The selection of the particular applications to include in a suite is made based on certain synergies desired to be achieved for a particular customer or group of customers. In this way a business customer, for example, may purchase a single suite that provides all of the applications to allow complete productivity for all of the functions that are normally performed in the business environment. This selection and grouping process by the OEMs and/or the VAPs greatly simplifies the decision process at the user level, and typically allows for a common user experience across applications since typically all applications will be from a particular OEM.
Another advantage provided by a suite of applications exists at the system administration level. Unlike the requirement of having to separately install and setup each individual application, entering the same user information over and over for each application, the installation of a suite is much more integrated. Most suites employ an installation wizard of some sort that installs and sets up all of the applications within the suite at one time. While this presents a distinct advantage over the individual application installation and setup, the structure and content of modem suites present problems for current installation processes that often result in confusion on the part of the user.
While many suites comprise a group of separate applications bundled together forming, in essence, an aggregation of applications as discussed above, more advanced and sophisticated suites actually comprise a multitude of inter-dependent applications. Indeed, many of the application programs themselves are actually mini-suites of related or complementary applications integrally operating as a xe2x80x9csinglexe2x80x9d application. Unfortunately, these mini-suites present additional problems that add to the user confusion.
One problem lying at the core of the user confusion relates to the type of installation actions available through the conventional installation programs, and the presentation of these options to the user via the conventional check-box user interface (UI). Traditional setup applications, such as that illustrated in FIG. 10 and FIG. 11, provide a user interface that shows a set or list of the components in the suite in a window 500 or list box. Next to each of the components of the suite is a small check box 502 or area that illustrates the selection or deselection of that component. Typically, a check mark is illustrated next to each component that will be installed in the default installation scenario.
This check box UI allows a user to decide which components she wants to install, and which components she does not want to install. In this situation, a check mark next to a component represents that that component will be installed (i.e. install component), and no check mark represents that that component will not be installed (i.e. do nothing). Unfortunately, when the user wanted to remove a component that was already installed, the user would click on a component that has a check mark next to it to remove the check mark. In this situation, a check mark next to a component represents that that component is already installed (i.e. do nothing), and no check mark represents that that component will be removed (i.e. uninstall component).
While such operation of current installation applications is functionally correct, the presentation and implementation can be a bit confusing to users. This confusion becomes apparent, for example, in situations where one or more of the components or sub-components included in a new suite are already installed on the user""s machine. In such a situation, when a user begins to setup and install the new suite, the installation application will detect the presence of these components and will place a check mark next to them in the UI. The installation application, however, also places check marks next to the components that are not currently installed, but that will be installed by the installation application. It is difficult, therefore, to determine from the displayed check marks which components the user will be installing and which components are already installed (in which case no action would be taken on those components). It is possible for a user to interpret the check mark as an install command, realize that she already has that component installed, believe that leaving the box checked will result in the re-installation of that component, and not wanting to re-install that component un-check the box. Unfortunately, this action will likely result in the component being removed from the user""s system because a non-checked box for an installed component is interpreted by many install applications as an uninstall request as described above.
Further, the check box interface used with most current installation applications provides the ability to request only two types of install actions. That is, the check box can be checked or not. As described above for a component that is not installed, the check signifies that the component will be installed, and no check signifies that the installation application will not install the component (i.e. do nothing). Also as described above, if the component is already installed, the check signifies that the installation application will leave the component installed (do nothing), and no check signifies that the installation application will uninstall the component. Some installation applications also provide a separate selectable option for components that are already installed, to wit, reinstall. When this additional option is selected, typically a separate UI screen is displayed, such as that illustrated in FIG. 12, with additional selectable options, such as xe2x80x9cremove allxe2x80x9d 504, xe2x80x9creinstallxe2x80x9d 506, and xe2x80x9cadd/removexe2x80x9d 508. However, if only one or a few of the components need to be upgraded to a current version, the only option is to select xe2x80x9creinstall,xe2x80x9d which will reinstall component that do not require any upgrade. This may require a significant amount of time to complete.
As may be apparent from the above description of the current check-box installation framework, the amount and types of install actions are limited to those described above. There is essentially no flexibility to add additional types of installation actions under this framework, or to allow a component to define particular component-specific actions to be performed. For example, components such as e-mail applications that have large data stores often place those stores on different drives than those on which the actual application is stored. In such situations, a disk failure for the application disk may leave the data stores totally intact. Since the data stores may include several hundred gigabytes of data, whereas the application may only require a few hundred megabytes, it is desirable to provide an additional install action other than reinstall all, which would not require a migration of the data stores. Unfortunately, while such programs can provide a xe2x80x9cforkliftxe2x80x9d or recovery option that would look for the data store and only reinstall the application without requiring the user to reconfigure the machine, no such additional action of this type is allowed under the current check-box framework. Therefore, a user could only choose xe2x80x9creinstall all,xe2x80x9d which action would require reconfiguration of the machine and migration of the data. Such actions typically take several days to complete for most organizations.
Therefore, there exists a need in the art to overcome these and other problems existing with the current state of suite installation programs. Specifically, there exists a need to present the installation actions to a user in a logical and easy to understand way that allows them to clearly see the state of the components affected, and what actions will be performed. Further, there exists a need to allow components to define custom installation actions and allow these custom actions to be included at the installation application run time.
The inventive concepts disclosed herein involve a new UI presentation and additional available custom actions for an installation application, such as a Suite Integration Toolkit (SIT). The system of the invention significantly improves the user experience during an installation of a suite of components by providing a rich set of install actions for user selection and by providing feedback information which is easy to understand.
The UI presentation and concepts behind the custom install actions of the instant invention solve the above identified and other problems by asking a component to provide a list of the install actions that it can support. Further, SIT recommends that the default actions (install, uninstall, and no action) be supported. The UI preferably presents this list to an end-user in a listbox that is displayed for each component upon selection of a drop-down arrow, allowing the user to select whichever install action works best for her. However, the display of this information may take other forms (or no UI allowing access instead via script). Additional information is conveyed to the user during the installation process, such as whether or not components are installed already on the computer. This information is presented in various forms, such as check marks, color differences, highlighting, etc.
The benefits of the instant invention are realized by having each of the components implement an ISetupComponent interface. This interface exposes a method to allow another component or manager of the Suite Integration Toolkit (SIT) to query the component for a specific interface, such as ISetupInstalLActionCollection. When this interface is queried, it returns a list of the available actions for that component. These actions may include custom actions that have no meaning outside of that particular component. The component is given the ability to define these custom actions, so long as the outcome thereof is provided to the SIT. Such actions may include, e.g., forklift, recovery, migrate, repair, etc. This extensibility of install actions in combination with the new UI greatly improves the user experience and releases the component constraints of prior installation applications.